@dcodeIO We definitely need tune inlining limits more better than binaryen's defaults.

Hmm, that's interesting. From looking over the inlining limits, this one seems as if it is smaller than flexibleInlineMaxSize = 20 and should be considered lightweight (maybe it isn't?), so it should inline if optimizeLevel >= 3 and shrinkLevel == 0. (see)

Yes, in -O3 it will be inlined but I guess even with shrinkLevel == 1 this should be possible. Only for shrinkLevel == 2 and 3 this unnecessary. -O3z used by default so it pretty important provide nearly identical speed with -O3 with just slightly smaller size

btw fan fact:
-O3 example with four isNaN: https://webassembly.studio/?f=tsbtqbkt2ks
has size: 123 bytes and with inlines

Same example but with -O3z: https://webassembly.studio/?f=4jfqpshboq9
142 bytes

I guess sometimes, when code is inlined, even if it doesn't meet the inlining criteria introduced to avoid growing, it can be optimized much better further down the road than if it remained its own small function. The challenge here seems to be to detect that condition, which would have to estimate how much inlining a function that isn't considered worth inlining at first actually benefits from other passes after inlining. Quite a hard problem, that doesn't seem to be solvable by just tweaking the inlining options because this would then also inline stuff that doesn't actually benefit from other passes. As such, I think Binaryen is doing what it reasonably can do without either recompiling multiple times to observe the difference or go completely crazy trying to build an estimator.

Maybe one assumption we could apply in Os is to ignore pushes to the stack involving function arguments, like the local.gets in this specific example, expecting that these will usually blend in fine into the call site? I'm guessing, but that's somewhat testable. We'd then have a conservativeSize and an eagerSize when checking worthInlining. Maybe. Perhaps.